home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 14368 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  7.1 KB
  1. Path: nntp.Stanford.EDU!rogoff
  2. From: rogoff@sccm.Stanford.EDU (Brian Rogoff)
  3. Newsgroups: comp.lang.ada,comp.lang.c++
  4. Subject: Re: some questions re. Ada/GNAT from a C++/GCC user
  5. Date: 29 Mar 96 16:30:36
  6. Organization: /u/rogoff/.organization
  7. Message-ID: <ROGOFF.96Mar29163036@sccm.Stanford.EDU>
  8. References: <wnewmanDoxrCp.DKv@netcom.com> <Dp1oAw.7Cz@world.std.com>
  9. Reply-To: rogoff@sccm.stanford.edu
  10. NNTP-Posting-Host: sccm.stanford.edu
  11. In-reply-to: bobduff@world.std.com's message of Fri, 29 Mar 1996 19:47:20 GMT
  12.  
  13. In article <Dp1oAw.7Cz@world.std.com> bobduff@world.std.com (Robert A Duff) writes:
  14.    > Is there any way in Ada to iterate abstractly over the contents of a 
  15.    > container,...
  16.  
  17.    Several ways:
  18.  
  19.        - Write a generic procedure Iterate, which takes a formal
  20.      procedure representing the body of the loop -- that is,
  21.      the formal procedure says what to do for each element.
  22.  
  23.        - Write a procedure that takes an access-to-procedure as
  24.      a parameter.  In standard Ada, this only works if the
  25.      procedure being passed in is non-nested, which makes this
  26.      technique fairly useless.  In GNAT, you can "cheat", by
  27.      using 'Unrestricted_Access, but that's not standard Ada.
  28.  
  29.        - Write an Iterator class.  Define any particular loop
  30.      by deriving from that, and overriding the Do_One_Element
  31.      method, or whatever.  I think there's an example in the
  32.      Rationale.
  33.  
  34.        - For each data structure, define Start, Done, Current_Element,
  35.      and Get_Next operations.  Or some variation on this.
  36.  
  37. Jon Anthony, where are you? :-)
  38. (FYI, Jon has a very nice approach to simulating Sather iters in Ada 95. I'll 
  39. leave it for him to post.)
  40.  
  41.    None of these is as pretty as the Sather solution, but they achieve the
  42.    main goal, which is to have the module that defines the data structure
  43.    define how to loop, and the clients define what they do at each
  44.    iteration.
  45.  
  46. The Sather iteration abstraction is great, and should be considered for 
  47. inclusion in future variants of Ada. Maybe now that GNAT exists, someone 
  48. will make an iter enhanced Ada like language (Sada? Sadie?).
  49.  
  50.    Macros can be used to achieve that, but in many cases, so can
  51.    procedures, generics, Sather's iterators, etc.  IMHO, the more
  52.    restricted features are generally better than macros.  Macros are more
  53.    powerful, but also more difficult to understand.  TeX is a language that
  54.    uses macros for just about everything, and I find TeX code to be totally
  55.    incomprehensible, despite the fact that I've read the TeX Book 4 times.
  56.  
  57. I agree, although just about any feature can be used to create unreadable code. 
  58. Even simple procedure abstraction (named procedures) could be used in an 
  59. obfuscatory manner (call "read" "write", "plus" "minus", etc.), though macros 
  60. give a lot of rope by which to hang yourself. There is supposedly some work by 
  61. Cardelli somewhere on the web about a clean approach to macros (yes I know about 
  62. Scheme; this is supposed to be different). OK, I found it (I love the Web :-), 
  63. it is called  "Extensible Syntax with Lexical Scoping" and is available at 
  64.  
  65.     http://www.research.digital.com/SRC/personal/Luca_Cardelli/Papers.html
  66.  
  67. No I haven't read it; a friend told me about it. Looks interesting...
  68.  
  69.    > Why doesn't Ada 95 allow declarations to be interspersed with ordinary
  70.    > statements as C++ does?  (Or does it?  _Ada as a Second Language_ is a
  71.    > big book!)  It seems to me that the C++ approach is a small but
  72.    > definite win.  Does it interact very badly somehow with all those
  73.    > guarantees on elaboration order?
  74.  
  75.    To intersperse declarations, you have to use a block_statement, like
  76.    this:
  77.  
  78.        for I in Some_String'Range loop -- I wish I could easily use an iterator here ;-)
  79.        declare
  80.            X: constant Character := Some_String(I);
  81.        begin
  82.            ...
  83.        end;
  84.        end loop;
  85.  
  86.    To me, the "declare", "begin", and "end" are just useless verbosity.
  87.    I prefer the C++ rule.
  88.  
  89. Yes, this seems needlessly verbose. Any Ada guru have a good reason why it has 
  90. to be this way?
  91.  
  92.    > Someone remarked -- in this newsgroup recently IIRC -- that macros
  93.    > were explicitly disallowed in the design goals for Ada (Ada 83?),
  94.    > since they make programs hard to understand.  I don't remember the
  95.    > exact wording, but as I remember the key reason was that you would
  96.    > never know what was a macro and what wasn't without reading the entire
  97.    > program hunting for macro definitions.  (I searched for `macro' in the
  98.    > Rationale without success, so I'm just going on speculation and dim
  99.    > memory here.)  It seems to me that that is a funny objection: most
  100.    > macro processors these days don't require a characteristic pattern to
  101.    > introduce macro expansions, but as far as I can tell there's no reason
  102.    > that you couldn't restrict macro expansion to e.g. patterns preceded
  103.    > by the keyword `macro'.
  104.  
  105.    I don't think this is the main reason people think macros are hard to
  106.    understand.  As you say, it would be easy to design the syntax so that a
  107.    macro invokation looks different from anything else.
  108.  
  109.    Macros are generally hard to understand for other reasons, I think.
  110.    Part of the problem is the low-level character-based nature of macros.
  111.    But as you point out below, that's not true of all known macro
  112.    facilities.  Part of the problem is the lack of scoping rules -- if a
  113.    macro expansion refers to a global variable X, it's referring to
  114.    whatever X happens to be lying around at the point of the macro
  115.    expansion.  Contrast that with Ada's generics, where the names are bound
  116.    at the site of the generic itself.  Part of the problem is that you have
  117.    to imagine what the macro expands to in order to understand what it
  118.    does, and complex code trasformations are hard to imagine accurately.
  119.    TeX macros have additional problems, like the fact that you can't tell
  120.    at the call site how many arguments are being passed -- in fact, you
  121.    can't in general tell until run time.
  122.  
  123. The Cardelli paper addresses the scoping issue (damn, now I'll have to read it).
  124. Here is the abstract:
  125.  
  126. Extensible Syntax with Lexical Scoping 
  127.  
  128. A frequent dilemma in programming languages design is the choice between a language 
  129. with a
  130. rich set of notations and a small, simple core language. We address this dilemma by 
  131. proposing
  132. extensible grammars, a syntax-definition formalism for incremental language extensions 
  133. ans
  134. restrictions. The translation of program written in rich object languages into a small 
  135. code language
  136. is defined via syntax-directed patterns. In contrast to macro-expansion and 
  137. program-rewriting
  138. tools, our extensible grammars respect scoping rules. Therefore, we can introduce binding
  139. constructs while avoiding problems with unwanted name clashes. We develop extensible
  140. grammars and illustrate their use by extending the lambda calculus with let-bindings,
  141. conditionals, and constructs from database programming languages, such as SQL query
  142. expressions. We then give a formal description of the underlying rules for parsing, 
  143. transformation,
  144. and substitution. Finally, we sketch how these rules are exploited in an implementation
  145.  of ageneric, extensible parser package. 
  146.  
  147.    - Bob
  148.  
  149.    P.S. I hope you enjoy Ada.  Why not get a copy of GNAT, and try it out?
  150.  
  151. Seconded!
  152.  
  153. -- Brian
  154.